Вчера мы писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1c, где главным нововведением стала интеграция функций миграции Advanced Cross vCenter Server vMotion Capability (ранее это был виртуальный модуль Cross vCenter Workload Migration Utility) в интерфейс vSphere Client. Оно же называется XVM.

Эта функциональность используется для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). При этом не требуется настроенного механизма Enhanced Linked Mode (ELM) или Hybrid Linked Mode (HLM) для серверов vCenter в разных датацентрах.

Один из главных сценариев такой миграции - это горячий перенос виртуальной машины из онпремизной инфраструктуры VMware vSphere в облачную среду VMC on AWS.

Для подобного рода миграций vMotion теперь есть 2 рабочих процесса: миграция ВМ на другой vCenter, а также импорт с целевого vCenter виртуальной машины источника:

Для функциональности XVM поддерживается и режим пакетной миграции, для которого вы можете указать несколько виртуальных машин, выбрать пункт Migrate и начать их одновременный перенос (пункт Cross vCenter Server export):

При миграции можно выбрать новый vCenter или один из уже сохраненных, что очень удобно при миграции групп ВМ в несколько заходов. К сожалению, Saved vCenters сохраняются только в рамках одной пользовательской сессии:

Дальше мастер будет похож на аналогичный в обычном vMotion, где будут выполняться стандартные предпроверки:

Как и при обычном vMotion, вы можете сменить хранилище виртуальной машины, а также ее сеть, чтобы она соответствовала инфраструктуре назначения. Затем начнется стандартная задача миграции:

На целевом vCenter тоже будет отображаться задача по приему vMotion от источника:

На целевом vCenter можно также самостоятельно инициировать прием миграции, выбрав пункт Import VMs из контекстного меню кластера:

Чтобы провести такую миграцию, также надо подключить исходный vCenter:

При успешном подключении вы сможете выбрать виртуальные машины, которые требуется перенести в другой датацентр:

Таким образом, эта функциональность может быть использована для следующих случаев:

• Миграция онпремизных ВМ в облачный датацентр VMC on AWS без необходимости настройки Hybrid Linked Mode (HLM)
• Переход на новую версию платформы vSphere путем переноса рабочих нагрузок со старых серверов
• Миграция ВМ в рамках обновления инфраструктуры VMware Cloud Foundation (VCF)
• Консолидация датацентров или перераспределение их содержимого
• Вывод из эксплуатации старого оборудования со старыми версиями vSphere
• Глобальная перебалансировка виртуальных машин между окружениями VCF
• Миграция инфраструктуры на одно из публичных облаков VMware Cloud

На днях компания VMware выпустила обновление VMware vSphere 7 Update 1c, в котором появилось довольно много всего нового для минорного апдейта.

Давайте посмотрим, что именно:

• Статистики по физическим сетевым адаптерам - добавилось 5 новых параметров (dropRx, dropTx, errorsRx, RxCRCErrors и errorsTx), которые позволяют вам обнаружить сетевые ошибки и предпринять действия по исправлению ситуации.
• Параллельное обновление хостов в кластерах, которые находятся под управлением vSphere Lifecycle Manager. Теперь хосты ESXi под управлением vLCM можно одновременно перевести в режим обслуживания и начать их обновление.
• Advanced Cross vCenter vMotion - это функциональность виртуального модуля Cross vCenter Workload Migration Utility, который был предназначен для переноса виртуальных машин средствами Cross vCenter vMotion между виртуальными датацентрами под управлением разных серверов vCenter (поддерживаются как единый SSO-домен, так и разные). Теперь эта штука интегрирована в vSphere Client, где удобно работать с миграциями ВМ между датацентрами (поддерживается и пакетная миграция нескольких ВМ):

• Можно подключать сторонние плагины для управления сервисами на платформе vSAN Data Persistence из vSphere Client таким же способом, как вы управляете сервером vCenter.
• Улучшения vSAN DOM scrubber (проверка блоков, к которым давно не было обращений).
• Улучшения Supervisor Cluster:
  • Изоляция пространств имен (Supervisor Namespace Isolation) за счет выделенного маршрутизатора T1 Router (кластеры в сети NSX-T используют для этого новую топологию).
  • Поддержка NSX-T 3.1 для Supervisor Clusters
  • Удалена поддержка Supervisor Cluster версий 1.16.x.
• Улучшения служб Tanzu Kubernetes Grid for vSphere:
  • Поддержка HTTP/HTTPS Proxy – вновь созданные кластеры Tanzu Kubernetes могут использовать глобальные прокси HTTP/HTTPS для исходящего трафика, а также скачивать образы контейнеров из интернет-репозиториев.
  • Вновь созданные кластеры Tanzu Kubernetes из коробки интегрированы со службой vSphere Registry Service. Также с этой службой будут интегрированы кластеры, обновленные до новой версии.
  • Кластеры Tanzu Kubernetes теперь могут монтировать дополнительные тома к виртуальным машинам, что позволяет увеличивать дисковую емкость узлов. Это дает возможность пользователям развертывать большие образы контейнеров, которые больше дефолтного размера в 16 ГБ.

Скачать VMware vSphere 7 Update 1c можно по этой ссылке. Release Notes доступны тут.

Не так давно мы писали о технологии vSphere Clustering Service (vCLS), которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Делается это за счет того, что на хостах есть агентские виртуальные машины служб vCLS.

Дункан Эппинг описал ситуацию, когда эти виртуальные машины просто не включаются с ошибкой в консоли vSphere Cleint:

Insufficient resources

Если посмотреть в детали сообщения об ошибке, то там будет примерно следующее:

The target host does not support the virtual machine's current hardware requirements.

Также может быть показано следующее сообщение:

Feature 'MWAIT' was absent, but must be present.

Выходов из этой ситуации может быть два - так как они могут быть обусловлены разными причинами. Причем первый вариант - это официально поддерживаемый со стороны VMware путь устранения проблемы для кластера в целом, а второй - "народный способ" для отдельных ВМ.

Вариант 1:

Для устранения ошибки про Feature 'MWAIT' нужно убедиться, что опция Monitor/MWAIT включена в BIOS (Enabled). vCLS включает EVC на базе виртуальных машин для каждой ВМ. Если же это не помогло или вы не можете это сделать, то нужно использовать метод, описанный ниже.

Вариант 2:

1. Апгрейдим ВМ в плане "Compatibility" до последней версии виртуального железа “VM version 14” (меню апгрейда есть по правой кнопке в vSphere Client).
2. Выбираем нужную ВМ, переходим на вкладку Configure и идем в VMware EVC.
3. Нажимаем "Edit" и выбираем “Yes” для подтверждения изменения настроек
4. Выбираем Disable EVC.
5. Повторяем это для всех виртуальных машин.

Как многие администраторы уже знают, 31 декабря этого года прекращается официальная поддержка технологии Adobe Flash большинством браузеров. Это в первую очередь затрагивает VMware vSphere Web Client, использовавшийся для управления старыми версиями VMware vSphere, когда новая платформа vSphere Client на базе HTML5 еще только развивалась (сейчас это полнофункциональный клиент, а старого веб-клиента больше нет). Напомним, что ранее была прекращена поддержка Internet Explorer.

Вот список продуктов и их версий, которые затронет отсутствие поддержки Flash со стороны браузеров:

В июне этого года, в связи с большим числом заявок от крупных компаний, было решено сделать Workaround для Flash Player. Чтобы включить его для отдельных URL, нужно внести изменения в файл mms.cfg, где следует добавить следующие строчки:

EOLUninstallDisable=1

EnabledAllowList=1

AllowListPreview=1

AllowListUrlPattern=https://FQDN/

Вместо FQDN нужно указать адрес вашего сервера vCenter, vCloud Director или веб-консоли другого продукта.

Вот где находится файл mms.cfg в зависимости от браузера и операционной системы:

Более подробно об этом рассказано в KB 78589.

На сайте компании Veeam появился кумулятивный Patch 3, который вы можете накатить на релиз продукта для резервного копирования и репликации виртуальных машин Veeam Backup and Replication 10a. Главная новая фича данного патча - это официальная поддержка новой версии платформы виртуализации VMware vSphere 7 Update 1.

Это уже третий кумулятивный патч после релиза версии 10а в июле этого года.

Давайте посмотрим на новые возможности, появившиеся в третьем патче к Veeam B&R v10a:

• Полная поддержка VMware vSphere 7.0 U1, включая обновленный vSphere API, а также виртуальных машин с Virtual Hardware 18.
• Автоматическое исключение из бэкапа системных ВМ, используемых службой vSphere Clustering Service (vCLS).
• Поддержка Microsoft Windows 10 20H2 и Microsoft Windows Server 20H2 как гостевых ОС, защищенных методом host-based backups и agent-based backups. Также туда можно поставить компоненты Veeam Backup & Replication.
• Поддержка дистрибутивов RHEL 8.3 и SLES 15 SP2 со стороны Veeam Agent for Linux 4.0.1.2372 - как в плане функций агента, так и в плане установки компонентов Veeam B&R.
• Добавлена поддержка S3-совместимого объектного хранилища со включенным версионированием и отключенным object lock (например, Backblaze B2).

Перед обновлением убедитесь, что номер билда вашей версии - это 10a (build 10.0.1.4854) в разделе Help -> About консоли Veeam Backup & Replication. После апгрейда номер билда должен измениться на 10.0.1.4854 P20201202.

Скачать Veeam Backup and Replication 10a Patch 3 можно по этой ссылке.

Компания VMware запустила новый ресурс core.vmware.com, посвященный технической информации для администраторов инфраструктуры VMware vSphere, решений vSAN, Horizon, vRealize и других платформ.

На новый портал переехал контент с ресурсов Storage Hub и vSphere Central, который был актуализован и теперь будет регулярно пополняться технической информацией в виде документов и видео.

Например, из интересного:

• VMware vSphere Security Configuration Guide 7 (а также секция Security)
• vMotion Enhancements in vSphere 7 (а также секция vSphere)
• vSphere with Tanzu Proof of Concept и Quick Start Guides

Документов будет много, но основной упор будет делаться на продукты vSphere, vSAN и Cloud Foundation.

Кстати, раз уж речь зашла о документации, расскажем, что VMware потихоньку начинает добавлять техническую документацию по продуктам на русском языке на сайт VMware Docs (мы писали об этом тут). Смотрите, например, что уже есть по vRealize Automation:

Недавно у компании VMware появился интересный документ "Performance Characterization of NVMe-oF in vSphere 7.0 U1", в котором рассказывается о производительности протокола NVMe-oF (NVMe over Fibre Channel).

Напомним, что NVMe-oF - это реализация технологии RDMA, которая позволяет не использовать CPU для удаленного доступа к памяти и пропускать к хранилищу основной поток управляющих команд и команд доступа к данным напрямую, минуя процессоры серверов и ядро операционной системы. Еще один его плюс - это то, что он обратно совместим с такими технологиями, как InfiniBand, RoCE и iWARP. Для всего этого нужна поддержка RDMA со стороны HBA-адаптера хоста ESXi.

Поддержка NVMe-oF для доступа к хранилищам появилась еще в VMware vSphere 7, а в обновлении Update 1 была улучшена и оптимизирована. В указанном выше документе рассматривается сравнение производительности традиционного протокола Fibre Channel Protocol (SCSI FCP) с реализацией FC-NVMe в vSphere 7.0 U1.

Для всех бенчмарков использовался тот же HBA-адаптер и инфраструктура сети хранения данных SAN. Для генерации нагрузки использовались утилиты fio (для создания разных по размеру операций ввода-вывода I/O, а также паттернов нагрузки) и Microsoft CDB (бенчмарк для генерации OLTP-нагрузки в SQL Server).

Результат оказался весьма интересным. С точки зрения IOPS протокол NVMe-oF смог выжать почти в два раза больше операций ввода-вывода практически для IO любого размера:

Задержка (Latency) также снизилась практически в два раза:

На картинке ниже приведены результаты теста Microsoft CDB для базы данных в числе транзакций в секунду:

Здесь также виден значительный прирост для NVMe-oF, а для двух виртуальных машин производительность выше почти в раза!

Остальные интересные детали тестирования - в документе.

На днях один из сотрудников компании VMware сделал аддон Helm Chart под решение vRealize LogInsight Cloud, который позволяет обрабатывать логи кластеров Kubernetes в среде VMware vSphere и TKG (Tanzu Kubernetes Grid).

Работает это решение в двух средах:

• Интегрированные кластеры Tanzu Kubernetes Grid (TKG) K8
• Отдельные инсталляции кластеров K8 на платформах vSphere/AWS

После установки аддона вы можете начать собирать метрики с кластеров TKG и K8 в вашем окружении, а также визуализовывать их на дашбордах наподобие вот такого:

Вообще Helm - это менеджер пакетов для Kubernetes. Это один из лучших путей поиска, шаринга и использования программного обеспечения в кластерах K8. Helm Charts это YAML-манифесты Kubernetes, объединенные в один пакет, который можно развернуть в среде K8. После запаковки установка Helm Chart в кластере производится одной командой helm, которая позволяет просто указать параметры развертывания и апгрейда.

Перед использованием данного средства вам понадобятся:

• Токен для vRealize LogInsight Cloud API
• Helm версии 3.x
• Административный доступ к кластеру Kubernetes

Итак, процедура по шагам:

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Получаем файл с переменными из рабочей директории:

helm show values loginsight-cloud/loginsight-cloud-helm > values.yaml

3. Обновляем параметры API Token и другие настройки, специфичные для вашей среды. Начинаем с команды:

cat values.yaml

4. Устанавливаем компонент Chart:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm -f values.yaml

5. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

6. Верифицируем релиз Helm:

helm list

Второй рабочий процесс установки (интерактивный режим):

1. Добавляем репозиторий Chart:

helm repo add loginsight-cloud https://munishpalmakhija.github.io/loginsight-cloud-helm/

2. Устанавливаем Chart в интерактивном режиме:

helm install test-vrlic loginsight-cloud/loginsight-cloud-helm --set vrlic.apikey=SETME --set tag.environment=DEMO

3. Верифицируем узлы Kubernetes Pods:

kubectl get pods -A | grep test-vrlic

4. Верифицируем релиз Helm:

helm list

После установки проверяем, что логи идут к LogInsight, это должно выглядеть следующим образом:

Чтобы начать пользоваться пробной бесплатной версией облака vRealize LogInsight Cloud, можно запросить триальную версию тут.

Это гостевой пост нашего спонсора - сервис-провайдера ИТ-ГРАД, предоставляющего виртуальные машины из облака в аренду. В 2016 году мы писали о решении VMware Cloud Foundation. По прошествии лет приведенную информацию следует актуализировать. В статье мы разберем примеры и кейсы его применения в реальных условиях.

Многие администраторы уже используют продукт VMware vSAN 7 Update 1 для создания отказоустойчивых кластеров хранилищ на базе серверов ESXi. Некоторое время назад мы писали про технологию Cloud Native Storage (CNS), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.

Давайте посмотрим, что нового появилось в возможностях CNS в обновлении vSAN 7 U1:

1. Расширение томов PersistentVolumeClaim

В Kubernetes v1.11 появились функции расширения томов за счет изменения объекта PersistentVolumeClaim (пока только офлайн). Помните, что уменьшение тома (shrink) не поддерживается.

2. Статический провижининг в Supervisor Cluster

Эта возможность позволяет презентовать существующий том в кластере K8s, который будет интегрирован с vSphere Hypervisor Cluster (он же Supervisor Cluster, vSphere with K8s, Project Pacific).

3. Поддержка vVols для vSphere K8s и TKG Service

Теперь обеспечивается поддержка внешних хранилищ на базе vK8s и TKG с использованием томов vVols.

4. Функции Data Protection for Modern Applications

В vSphere 7.0 U1 появились функции поддержки резервного копирования Dell PowerProtect и Velero для Pacific Supervisor и TKG кластеров. Для Velero вы можете инициировать создание снапшотов через Velero plugin и хранить их в облаке S3.

5. Функции vSAN Direct

Возможность vSAN Direct позволяет использовать Direct Attach Storage (обычно на базе физических HDD-дисков) для хранения виртуальных машин VMware vSphere.

Вы можете создавать vSAN Direct Datastores, которые не являются общими для кластера датасторами, но физические диски таких хранилищ можно, например, напрямую подключать к виртуальным модулям (Virtual Appliances) или к контейнерам, исполняемым в среде vSphere, которым нужно объектное хранилище, но при этом хочется использовать его напрямую, минуя стандартный путь данных vSAN.

Мы уже много писали о новых возможностях платформы виртуализации VMware vSphere 7 Update 1. Сегодня мы посмотрим подробнее, что нового появилось в плане механики резервного копирования виртуальных машин (Data Protection), реализуемой через VMware vStorage API for Data Protection.

1. Функции Network QoS для трафика резервного копирования

Теперь возможности приоритезации трафика Network QoS доступны и для трафика резервного копирования виртуальных машин. Настроить это можно в vSphere Client в разделе System Traffic > Configure > Edit:

Основное назначение данной настройки - дать возможность урезать полосу канала резервного копирования таким образом, чтобы это не влияло существенным образом на трафик производственной среды.

2. Улучшенная обработка задач резервного копирования

Теперь при входе хоста ESXi в режим обслуживания во время резервного копирования есть флаг Entering Maintenance Mode (EMM), что означает, что операции бэкапа должны переключиться на другой хост ESXi, где сессия NFC (network file copy) может быть продолжена. Это автоматическое переключение происходит прозрачно для задачи резервного копирования, но требует от ПО для бэкапа поддержки данного флага, чтобы обнаружить момент переключения.

3.Улучшенное масштабирование для одновременно запущенных задач РК

Для окружений, где параллельно запущено множество задач резервного копирования, ограничения сервера vCenter могут стать проблемой. Использование сервиса VPXA не позволяет кастомизировать буфер памяти для задач, обрабатываемых через vCenter. В апдейте vCenter Server 7.0 U1 теперь можно настраивать буфер памяти, чтобы обрабатывать множество потоков резервного копирования. Например, для 50 одновременных бэкапов нужно использовать 96 MБ памяти.

4. Улучшения vSphere APIs for I/O Filtering (VAIO)

Фреймворк VAIO - это основной интерфейс для партнерских решений, которые могут перехватывать запросы ввода-вывода операционной системы к виртуальному диску. В этом случае команда ввода-вывода (I/O) не будет применена к диску без прохождения через IO Filter, созданный сторонним ПО.

Теперь здесь появились следующие улучшения:

• CIM provider теперь стал 64-битным
• Сами VAIO-фильтры теперь будут распространяться как компоненты, а не VIB-пакеты

Напомним, что в vSphere 7 появилась концепция компонентов вместо отдельных VIB-пакетов. В vSphere 7 компоненты - это набор VIB-пакетов, которые может использовать Lifecycle Manager, чтобы накатывать патчи. Теперь компоненты можно накатывать через esxcli с использованием команды component apply.

На сайте virten.net (клевый, кстати, ресурс) появилось описание серьезной ошибки файловой системы VMware VMFS 6, которая используется для создания датасторов в ESXi 7.0 (Build 15843807) и 7.0b (Build 16324942). Он касается кучи ФС (VMFS heap), которая переполняется из-за некорректной работы механизма ее очистки. В VMware vSphere 7 Update 1 эта ситуация решена. Сама проблема описана в KB 80188.

Симптомы переполнения кучи, как правило, следующие:

• Датасторы на хостах показывают статус "Not consumed"
• Виртуальные машины не могут выполнить vMotion
• Виртуальные машины "сиротеют" (переходят в статус "orphaned") при выключении
• При создании снапшота возникает ошибка "An error occurred while saving the snapshot: Error."

В логе vmkernel.log могут появляться следующие сообщения об ошибках:

• Heap vmfs3 already at its maximum size. Cannot expand
• Heap vmfs3: Maximum allowed growth (#) too small for size (#)
• Failed to initialize VMFS distributed locking on volume #: Out of memory
• Failed to get object 28 type 1 uuid # FD 0 gen 0: Out of memory

Память для кучи VMFS принудительно очищается при аллокации ресурсов файловой системы, например, обычных thick-дисков. Поэтому воркэраунд получается следующий - нужно создать диск Eager zeroed thick на всех смонтированных к хостам ESXi датасторах. Делается это командой:

# vmkfstools -c 10M -d eagerzeroedthick /vmfs/volumes/datastore/eztDisk

Удалить этот диск можно командой:

# vmkfstools -U /vmfs/volumes/datastore/eztDisk

Проблема только в том, что нужно выполнить эту операцию на каждом датасторе каждого хоста. Поэтому есть вот такая команда для всех датасторов и хостов:

# for I in $(esxcli storage filesystem list |grep 'VMFS-6' |awk '{print $1}'); do vmkfstools -c 10M -d eagerzeroedthick $I/eztDisk;echo "Removing disk $I/eztDisk"; vmkfstools -U $I/eztDisk; done

Результат будет примерно таким:

Сейчас какого-то отдельного патча для решения этой проблемы нет, поэтому нужно самостоятельно следить за поведением инфраструктуры. Основным симптомом является появление в vmkernel.log следующего сообщения:

Maximum allowed growth * too small for size

Если у вас есть такой продукт, как VMware Log Insight, то вы можете настроить аларм на появление этого сообщения в логе.

Многие администраторы платформы VMware vSphere задаются вопросом - что произойдет, если изменить политику хранилищ (Storage Policy) в кластере vSAN для виртуальной машины? Будет ли после этого выполнена операция по перестроению дисковых объектов (Rebuild), что повлечет дополнительную нагрузку на хранилища и займет время?

Также в некоторых условиях операция Rebuild может не выполняться, но выполняется Resync - добавление новых копий данных, при котором исходные копии данных не изменяются (например, вы увеличиваете значение политики FTT, что влечет создание новых дисковых объектов).

Ответ на этот вопрос зависит от того, какую политику и на что вы меняете. Дункан Эппинг провел полезные тесты в своей лабе, чтобы выяснить, в каких случаях происходит Rebuild/Resync. После каждой операции он через интерфейс командной строки проверял, происходила ли операция ресинхронизации. Далее он свел полученные результаты в таблицу ниже, чтобы при изменении политики администраторы vSAN представляли, что произойдет дальше.

Собственно, таблица:

Многие из вас знают про лучшее на рынке программно-аппаратное решение для организации хранилищ под виртуализацию StarWind Virtual SAN. О прошлом его обновлении, которое вышло весной этого года, мы писали вот тут.

Недавно компания StarWind выпустила обновление этого продукта в виде виртуального модуля OVF на базе Linux для VMware vSphere - VSAN OVF Version 20201027 Version 8 (build 13861).

Давайте посмотрим, что там появилось нового:

Общие улучшения и багофиксы

• Обновлено ядро модуля Linux Kernel.
• Настройка iScsiPingCmdSendCmdTimeoutInSec теперь по умолчанию выставлена в 5 секунд.
• Исправленный процесс логирования для оповещений по email, теперь они не смешиваются с общими событиями почтового сервера.
• Улучшены операции по остановке службы (ранее этот процесс мог подвиснуть в определенных обстоятельствах).
• Обновлена имплементация SCSI-протокола для более корректного процессинга команд UNMAP/TRIM.

Улучшения синхронной репликации

• Добавлена опция использования SMB-шары как ресурса witness для устройств с синхронной репликацией.
• Исправлена обработка персистентных резерваций для устройств с синхронной репликацией.
• Исправлены некоторые случаи обновления состояния партнерского узла после восстановления из ситуации split-brain.

Управляющая консоль (Management Console)

• Исправлено падение консоли, когда StarWind Event log содержал записи с некорректными строковыми значениями.
• Обновлен диалог настроек нотификаций по email (добавлена валидация и спрятаны поля логина-пароля при отсутствии необходимости аутентификации).

Модуль StarWindX PowerShell

• Добавлена возможность добавления HA-устройств в конфигурации Node Majority. Теперь узел StarWind или SMB-шара могут быть использованы как witness. Более подробно об этом можно узнать из примеров сценариев CreateHAPartnerWitness.ps1 и CreateHASmbWitness.ps1.

• Поправлена обработка параметра ALUA для командлетов по созданию HA-устройства.

Скачать пробную версию StarWind Virtual SAN для VMware vSphere в формате виртуального модуля OVF можно по этой прямой ссылке.

Многие администраторы VMware vSphere знают, что у этой платформы есть режим совместимости Enhanced vMotion Compatibility (EVC), который позволяет привести хосты с процессорами (CPU) разных моделей к единому базовому уровню по набору возможностей CPU Feature Set, чтобы обеспечить свободную миграцию vMotion между хостами ESXi. Делается это за счет маскирования некоторых наборов инструкций процессора через CPUID.

Сейчас многие приложения (например, реализующие техники Machine Learning / Deep Learning) используют ресурсы графического адаптера (GPU), поскольку их многоядерная архитектура отлично подходит для такого рода задач.

В VMware vSphere 7, вместе с соответствующей версией VM Hardware, были существенно улучшены функции работы для режима vSGA, который предназначен для совместного использования графического адаптера несколькими виртуальными машинами хоста.

Поэтому в VMware vSphere 7 Update 1 сделали еще одно полезное улучшение по этой теме - режим Enhanced vMotion Capabilities для графических процессоров GPU, который является частью EVC, настраиваемого в vSphere Client:

Графический режим VMFeatures включает в себя поддерживаемые возможности для 3D-приложений, включая библиотеки D3D 10.0/ Open Gl 3.3, D3D 10.1 / Open GL 3.3 и D3D 11.0 / Open GL 4.1. Пока приведение к базовому уровню доступно только до D3D 10.1 / OpenGL 3.3 (версии 11.0 и 4.1, соответственно, будут поддерживаться в следующих релизах).

Когда хост ESXi включается в кластер, где включена EVC for Graphics, сервер vCenter проверяет, что он поддерживает соответствующие версии библиотек. При этом можно добавлять хосты разных версий - ESXi 6.5, 6.7 и 7.0, благодаря поддержке D3D 10.0 и OpenGL 3.3.

Как и для обычного EVC, пользователи могут включить EVC for Graphics на уровне отдельных ВМ. В этом случае перед тем, как включить виртуальную машину на хосте ESXi, сервер vCenter убеждается, что он поддерживает соответствующие библиотеки. Такая настройка полезна при возможной миграции виртуальной машины между датацентрами или в публичное облако.

Если у вас включена EVC for Graphics, то перед миграциями vMotion также будут проводиться нужные предпроверки по поддержке графических функций GPU со стороны видеоадаптера целевого хоста.

Мы уже довольно много писали о нововведениях и улучшениях недавно обновленной версии платформы VMware vSphere 7 Update 1, а также средств создания отказоустойчивых кластеров VMware vSAN 7 Update 1. Между тем, наши читатели указывают нам на интересные нововведения в части функций по работе с хранилищами в апдейте платформы (Core Storage Enhancements).

Если вы хотите подробно почитать обо всех функциях хранилищ в vSphere 7 Update 1, то рекомендуем посмотреть вот этот документ - "vSphere Storage" (но там 400 страниц, имейте в виду):

Давайте посмотрим, что из нового заслуживает внимания:

1. Улучшения VMFS

Тут 2 основных момента:

• Процесс создания снапшота SESparse был улучшен - теперь он меньше раздувается, а также требуется меньше места в процессе консолидации снапшотов. Также улучшилось отображение прогресса консолидации.
• Уменьшилось время "замирания" файловой системы при создании или удалении снапшотов. Это произошло за счет доработки механизма взаимодействия Affinity Manager и Resource Clusters (RC).

2. Доработки томов vVols

• Поддержка томов vVols как основного хранилища для VMware Cloud Foundation (VCF).
• Поддержка томов vVols для Tanzu и Cloud Native Storage (CNS).
• Оптимизация миграций виртуальных машин и операций Storage vMotion для тонких дисков - это уменьшает время, необходимое на миграцию виртуальных машин между томами vVols.
• Оптимизация операций по привязке томов vVols - теперь при включении нескольких виртуальных машин одновременно эти операции выполняются в пакетном режиме, что увеличивает производительность за счет меньшего числа VASA API вызовов.
• Поддержка VASA для метода аутентификации CHAP на томах vVols через iSCSI.

3. Улучшения NFS

• Для NAS VAAI появилась возможность установки плагинов без перезагрузки.
• Раньше клонирование NVDK или LZT диска падало с ошибкой, теперь же для них все отрабатывает отлично.

4. Функция расширения pRDM со службами Microsoft WSFC

• Была добавлена поддержка горячего расширения disk/LUN для режима pass-through RDM, использующегося в кластерах Windows Server Failover Clustering (WSFC).

5. Функции NVMeoF

• Поддержка Oracle RAC при использовании таргетов NVMeoF

Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).

Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:

То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:

Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.

Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).

Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:

• Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
• Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
• Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.

Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.

Чтобы у вас работала технология PVRDMA для Native Endpoints:

• ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
• Гостевая ОС должна поддерживать RDMA namespaces на уровне ядра (Linux kernel 5.5 и более поздние).
• Виртуальная машина должна иметь версию VM Hardware 18 или более позднюю.

За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.

На сайте проекта VMware Labs появилась очередная полезная штука - Storage Performance Tester. С помощью данного средства администраторы VMware vSphere могут в один клик проверить производительность хранилищ в плане IOPS, Latency и циклов CPU на одну операцию ввода-вывода для серверов VMware ESXi.

Эта утилита автоматизирует все шаги, которые необходимо предпринять для тестирования, включая развертывание виртуальных машин, запуск нагрузки по вводу-выводу, а также анализ производительности хранилища. Метрики, полученные в результате тестирования, визуализируются на графиках. Единственная вещь, которую вам нужно сделать - это выполнить соответствующую команду и ждать сгенерированного отчета о производительности хоста ESXi.

Средство создано как для администраторов платформы vSphere, так и для разработчиков, которым требуется решать проблемы производительности в виртуальной инфраструктуре. Также Storage Performance Tester удобно использовать для получения максимальных параметров производительности аппаратного обеспечения, а также программных компонентов (драйверы, настройки vSphere и vSAN).

Для запуска тестовой среды вам понадобятся:

• python3
• sshpass
• 2 ГБ свободного места
• Linux-окружения (с версией ядра не менее 2.6.31)

Вот небольшое обзорное видео, где можно посмотреть всю процедуру запуска утилиты и, собственно, сам отчет с результатами тестирования:

Скачать Storage Performance Tester можно по этой ссылке.

Не так давно мы писали о том, что в последней версии VMware vSphere 7 Update 1 технология vMotion стала еще быстрее и теперь обеспечивает нужды горячей миграции даже для самых тяжелых виртуальных машин.

Напомним, что VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.

Недавно был выпущен интересный и полезный документ "vMotion Innovations in VMware vSphere 7.0 U1 - Performance Study", в котором VMware суммаризовала основные улучшения, сделанные в vMotion.

Интересны некоторые моменты. Например, в vSphere 6.7 используется технология отслеживания изменений CPU во время миграции stop-based trace, которая "подмораживает" все CPU, а в vSphere 7 U1 уже подмораживается только один процессор (техника loose page-trace Install):

Также vSphere 7.0 U1 передает compacted bitmap памяти вместо полного, что уменьшает время переключения на ВМ другого хоста:

Интересно уменьшение влияния миграции тяжелой БД Oracle на производительность - улучшение составило 19 раз!

Время миграции - до 50% меньше:

Ну и вообще в документе очень много всего интересного для интересующихся. Читайте здесь.

Wolfgang Taitl в своем блоге обратил внимание на серьезную проблему, касающуюся некоторых NFS-хранилищ и процесса создания резервных копий виртуальных машин на VMware ESXi. Это известная проблема.

Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.

Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.

При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.

После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:

• Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
• Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
• Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
• Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.

На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.

У компании VMware есть отличное решение Log Insight, которое предназначено для поиска любых данных в виртуальной инфраструктуре, анализа лог-файлов и визуализации аналитики. На прошедшем VMworld Online 2020 была представлена версия Log Insight 8.2.

Если вы администратор VMware vSphere, то наверняка имели необходимость заглядывать в лог vmware.log, который находится в папке с виртуальной машиной, для поиска некоторых событий и решения проблем с данной ВМ. Там могут находиться события reconfiguration events, миграции vMotion, сообщения VMware tools, memory state, события power on/off, включаемые фичи, API-запросы и многое другое.

Все эти сообщения можно отправлять в реальном времени для мониторинга со стороны VMware vRealize Log Insight и отлавливания их с помощью алертов по заданным параметрам. Делается это с помощью возможностей Interactive Analytics.

Файл vmware.log находится в папке с виртуальной машиной и имеет некоторую ротацию:

Чтобы посылать данные лога в Log Insight, нужно изменить Configuration Parameters для ВМ. Для этого сначала выключаем ее, идем по правой кнопке в Edit settings в vSphere Client, выбираем вкладку VM Options и кликаем Edit Configuration:

Далее нужно нажать Add Configuration Params:

После этого добавляем параметр vmx.log.syslogID со значением <vmname>_vmx_log, где vmname - это имя виртуальной машины. Этот айди будет передаваться в Log Insight:

Далее включаем виртуальную машину и на вкладке Interactive Analytics в Log Insight видим, что машина генерирует больше 2000 событий, у этих событий есть типы:

Далее мы можем сформировать запрос на поиск того или иного события и сделать из него алерт с определенным действием (например, отправить webhook или в Operations Manager).

В данном случае происходит отправка письма администратору:

Чтобы отключить логирование, нужно просто удалить значение из поля vmx.log.syslogID:

Пару недель назад компания VMware анонсировала обновление своей платформы Cloud Director 10.2, предназначенной для создания интегрированной среды сервис-провайдеров, предоставляющих виртуальные машины в аренду своим клиентам. Напомним, что о прошлой версии vCD 10.1 мы писали в мае этого года вот здесь.

Ну а на прошедшем VMworld новым возможностям была посвящена сессия HCPS2407 (по этому тексту ее и нужно искать тут):

Давайте посмотрим, что появилось нового в vCD 10.2. Основные области нововведений представлены на картинке:

1. Единая инфраструктура для гибридной среды

Компания VMware делает ставку на то, что крупные компании будут строить гибридные инфраструктуры из собственных площадок и ресурсов сервис-провайдеров, поэтому теперь VMware Cloud Director on-premises и службы VMware Cloud Director в VMware Cloud on AWS имеют единую базу кода, то есть представляют собой один базовый продукт.

Соответственно, и администраторы, и клиенты облака могут управлять инфраструктурой в любом облаке, действуя в единой гибридной среде в рамках предоставленных полномочий.

2. Глобальная доступность VMware Cloud Director 

В четвертом квартале 2020 года ожидается, что службы VMware Cloud Director будут доступны по всему миру, включая наш с вами регион EMEA. При этом администраторы смогут управлять инстансами в разных регионах, если будет выполнено основное условие по latency<150 миллисекунд между площадками.

3. Улучшенная интеграция NSX-T со службами Network & Security

NSX-T в связке с Cloud Director будет предоставлять следующие возможности в облачной инфраструктуре:

• Поддержка распределенного сетевого экрана L4-7 и расширенных функций, таких как VRF lite.
• Улучшения интерфейса, которые позволят растягивать сеть между несколькими виртуальными датацентрами на разных площадках, что позволит применять политики распределенного фаервола к гибридным окружениям.
• Сети клиентов от собственного датацентра к сервис-провайдеру можно будет соединить по layer 2 VPN, вне зависимости от онпремизной версии NSX (NSX-V или NSX-T).
• NSX Advanced Load Balancer (он же Avi Networks Load Balancer) заменит нативный балансировщик NSX-T Load Balancer в издании NSX-DC Base Edition. Это также даст такие возможности, как WAF, DNS, SSL Termination, rate-limiting и другие в решении NSX ALB Enterprise edition.

4. Улучшения в поддержке Kubernetes

В этой сфере появится два основных нововведения:

• Службы Containers as a Service with Tanzu - теперь в Cloud Director будет интегрировано решение VMware vSphere with VMware Tanzu, что позволит сервис-провайдерам производить оркестрацию кластеров K8s прямо из нативных средств управления vSphere и vCD. Для развертывания контейнерных сред можно будет использовать Container Service Extension 3.0, который дает функции по управлению жизненным циклом всех типов кластеров через Cloud Director Cluster API, CLI и Container Service Extension-CLI, а также плагин в графическом интерфейсе.
• Новое средство Cloud Director App Launchpad 2.0, которое позволит клиентам облаков использовать приложения и не думать о нижележащей инфраструктуре. Сервис-провайдеры смогут предложить маркетплейс для пользователей, где они смогут выбрать приложения (на базе контейнеров или виртуальных машин). Вторая версия лончпада поддерживает Container Service Extension 3.0, что позволит пользователям запускать приложения в инфраструктуре Org VDC или кластере K8s автоматически. Будут поддерживаться и кастомные приложения, а также будет реализована тесная интеграция с VMware Cloud Marketplace, что позволит, например, автоматически синхронизировать приложения с выходом их новых версий.

5. Упрощенные функции развертывания Cloud Director

Теперь vCD будет развертываться с помощью переработанного мастера, а также производить внутреннюю проверку на ошибки. Также будет проверяться ввод пользовательских данных и проводиться автоматические бэкапы при установке.

6. Улучшения гибкости и повышение эффективности хранилищ

• Cloud Director 10.2 будет интегрирован с конфигурациями vSphere Storage Policy-based IOPS, что позволит настраивать Storage I/O Control для ресурсов Storage I/O на базе отдельных ВМ из административного интерфейса
• Можно будет использовать shared disks для кластеров Microsoft и Oracle, а также персистентных томов.
• Object Storage Extension (OSE) 2.0 будут позволять клиентам управлять их сервисом AWS S3 через OSE.
• Также OSE 2.0 будет предоставлять поддержку Cloudian 7.2 и Dell ECS 3.4.
• В портале для клиентов будет множество улучшений (например, Guided Tours для обращения внимания на предлагаемые сервисы и фичи), нотификаторы для разных ситуаций (Advisories), а также функции поиска Quick Search.

7. Расширенное предоставление информации клиентам об их облаках

Приложение для клиентов vRealize Operations Tenant App 2.5 будет улучшено в самых разных аспектах, включая поддержку Container Service Extension Kubernetes Clusters, что позволит получать больше информации о приложениях в контейнерах. Также будут предоставлены широкие возможности по созданию и кастомизации отчетов об инфраструктуре. Кроме того, можно будет кастомизировать email-оповещения для клиентов с учетом их потребностей.

Доступность VMware Cloud Director 10.2 ожидается до конца четвертого квартала этого года, следите за новостями.

Пару недель назад компания VMware сделала очень много интересных анонсов в рамках онлайн-конференции VMworld 2020 Online, самые интересные из которых мы собрали вот тут.

Одним из таких анонсов стал выпуск новой версии решения vRealize Automation 8.2, предназначенного для автоматизации большинства рутинных операций в облаке на базе VMware vSphere (то, что раньше делалось только с помощью Orchestrator). О версии vRealize Automation 8.0 с прошлого VMworld мы писали вот тут.

Давайте посмотрим, что нового появилось в vRealize Automation 8.2:

• Объекты VMware Cloud Templates (ранее они назывались vRealize Automation Blueprints), реализующие механизм шаблонов для инфраструктуры VMware Cloud в части развертывания и оркестрации. В последнем релизе есть поддержка решений VMware Cloud Foundation, Kubernetes, NSX, а также расширенные интеграции со сторонними решениями, такими как Terraform и ServiceNow.

• Улучшенный механизм multi-tenancy с функциями централизованного управления инфраструктурой клиентов (тенантов) за счет функций Virtual Private Zones:

• Кастомный движок ролевой модели Role Based Access Control (RBAC):

• Возможность утверждения действий Day 2 actions для всех элементов каталога сервисов.

• Также была реализована поддержка First Class Disks (FCD):

• Функции облака самообслуживания - появилась очень тесная интеграция с архитектурой VMware Cloud Foundation (VCF).

• Улучшенные действия Day 2:

• Поддержка интерфейса NSX-T Policy API:

• Улучшения инфраструктуры DevOps - новый подход шаблонизации Infrastructure as Code (IaC) для инфраструктуры VMware Cloud на базе движка VMware Cloud Templates. Также можно определять и шарить действия (Actions) с помощью механизма Action Based Extensibility (ABX).

• Автоматизация Kubernetes - возможность самостоятельного развертывания пространств имен Kubernetes через каталог сервисов с учетом механизма IaC.

• Мастер обследования миграции Migration Assistant для выяснения способности миграции исходного окружения vRealize Automation 7 на версию 8.2:

Скачать VMware vRealize Automation 8.2 можно по этой ссылке. Release notes доступны тут.

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Одним из лидеров отрасли является решение StarWind Virtual SAN, у которого есть множество функций хранения, обеспечения доступности и защиты данных. А сегодня мы поговорим еще об одном бизнесе компании StarWind - программно аппаратных комплексах для специальных задач...

На прошлой неделе компания VMware выпустила новую версию своего основного руководства по обеспечению информационной безопасности виртуальной инфраструктуры VMware vSphere Security Configuration Guide 7 (SCG 7). Теперь документ содержит 78 настроек, так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин.

Что нового появилось в руководстве:

• Совместимость с гайдлайнами по безопасности NIST 800-53, NIST 800-171, CMMC, PCI DSS, ISO 27001, NERC CIP
• Учет аппаратных уязвимостей CPU, таких как Meltdown и Spectre
• Покрытие конфигурациями новых технологий и функциональности платформы vSphere 7

Напомним, что этот документ доносит концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований в вашей инфраструктуре.

В документе, помимо описания рекомендуемой настройки и лога изменений, есть следующие полезные колонки:

• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено администратором необоснованно. 
• Desired value - рекомендуемое значение, оно же и является значением по умолчанию, если это не site specific.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.

Помимо основного Excel-файла с настройками, в составе скачиваемого архива есть и руководство по применению настроек и работе с ними:

Скачать VMware vSphere Security Configuration Guide 7 одним архивом можно по этой ссылке. Конечно же, документ стоит посмотреть всем специалистам по ИБ, в компетенцию которых входит работа с безопасностью виртуальной инфраструктуры.

Как вы все знаете, на прошлой неделе прошла главная конференция по виртуализации этого странного года - VMworld 2020 Online. Несмотря на то, что она прошла онлайн, было сделано немало интересных объявлений, а перед самой конференцией были анонсированы главные обновления продуктовой линейки. Одним из них был скорый выпуск новой версии платформы VMware vSphere 7 Update 1, который и состоялся:

На днях также появилась возможность скачать новые версии нескольких продуктов, помимо vSphere 7 U1. Давайте посмотрим, какие именно решения были выпущены:

Скоро постараемся написать о том из этого, о чем еще не рассказали. Заходите чаще!

На сайте проекта VMware Labs появилось очередное бесплатное средство для администраторов VMware vSphere - SQL30. Эта штука представляет собой ORM-обертку для легковесной БД SQLITE под ESXi.

Python нативно поддерживает взаимодействие с SQLITE за счет модуля "sqlite" (или sqlite3 в python3). Ну а решение SQLAlchemy - это популярная ORM, используемая для взаимодействия с базами данных sqlite из Python. Однако это решение не работает на ESXi, так как многие его пакеты имеют зависимости от других пакетов, которые не могут быть установлены на ESXi.

Решение SQL30 как замена SQLAlchemy - весьма легковесно и написано только с использованием нативных конструкций Python, а также не имеет никаких внешних зависимостей, поэтому работает на ESXi 6.5 и более поздних версиях.

SQL30 вам пригодится для:

• Возможности использования разработчиками интерфейсов Python на платформах с ограниченным применением, таких как ESXi
• Предоставления разработчикам приложений доступа к базе данных без необходимости знания SQL

На VMware ESXi 6.5 будет использоваться версия Python 3.5, что ниже актуальной версии 3.6, но все равно лучше чем ничего.

Скачать SQL30 можно тут. Инструкции по установки приведены вот здесь.

Какое-то время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere 7 Update 1. Одним из главных улучшений стало увеличение максимальных параметров платформы, что привело к возможности организовывать кластер HA/DRS из еще большего числа хостов, а на самих хостах - исполнять виртуальные машины еще большего размера.

Данные нововведения можно проиллюстрировать следующей таблицей:

В кластере теперь может быть до 96 хостов, правда не все технологии поддерживают это число. Например, кластер VMware vSAN 7 Update 1 и топология HCI Mesh поддерживают все еще 64 хоста, а технология Native File Services в vSAN 7 U1 поддерживает только 32 хоста.

Самое большое улучшение - теперь в кластере может быть до 10 тысяч виртуальных машин, а это на 50% выше показателя vSphere седьмой версии:

Для виртуальных машин, находящихся под экстремальной нагрузкой, теперь поддерживается 768 виртуальных процессоров (vCPU) и до 24 ТБ памяти. Это больше, чем для виртуальных машин на любой из других облачных или онпремизных платформ:

К подобным нагрузкам можно отнести системы на базе SAP HANA и EPIC Cache Operational Database. Все эти ресурсы виртуальная машина может реально использовать:

Для виртуальной инфраструктуры в целом на базе одного кластера в Sphere 7 Update 1 максимальные показатели следующие: 393 216 vCPU (96 хостов по 4 096 vCPU) / 2.3 ПБ памяти (96 хостов по 24 ТБ):

Если говорить об исполнении контейнеров vSphere with Tanzu в такой инфраструктуре, то их может поместиться просто огромное количество. Согласно статистике, средний размер контейнера составляет 1 vCPU и 400 МБ памяти (например, контейнер node.js "кушает" 1/3 CPU и 384 МБ памяти). Таких контейнеров в одном кластере vSphere 7 U1 может быть запущено 393 216 штук. А контейнеров node.js можно запустить до миллиона экземпляров!

Многие из вас знают, что компания VMware с каждым новым релизом мажорной версии платформы vSphere улучшает техники горячей миграции виртуальных машин vMotion. Последнее обновление VMware vSphere 7 Update 1 - не исключение, там было сделано много для того, чтобы технология vMotion работала еще быстрее и обеспечивала нужды горячей миграции даже для самых тяжелых виртуальных машин.

Ранее vMotion могла не пройти для больших ВМ, которые имели более 64 vCPU и 512 ГБ памяти (они же Monster VMs). В документе "vMotion Innovations in vSphere 7.0 U1" можно найти конкретное описание улучшений. Давайте посмотрим на них вкратце.

Прежде всего, VMware полностью переписала технологию vMotion memory pre-copy с использованием нового механизма page-tracing, который существенно уменьшает время "заморозки" и переключения копии виртуальной машины на ее копию на другом хосте ESXi.  

В документе выше для примера делается миграция vMotion сервера БД Oracle, запущенного в виртуальной машине с 72-vCPU / 1 TБ памяти на борту. На картинке ниже показано число тразакций в секунду с шагом как раз в секунду - до, во время и после vMotion (тест HammerDB):

Основные выводы теста, проведенного для такой нагрузки:

• Общее время миграции уменьшилось более чем в 2 раза (с 271 секунды до 120 секунд)
• Итоговое время для установления трассировки уменьшилось с 86 секунд до 7.5 секунд (снизилось в 11 раз)
• Общее проседание пропускной способности во время миграции - на 50% для vSphere 6.7 и всего лишь 5% для vSphere 7.0 Update 1
• Ответ Oracle во время переключения в среднем стал менее одной секунды, а ранее составлял более 6 секунд

Второй тест проводили для миграции vMotion сервера БД Oracle в виртуальной машине с 12 vCPU / 64 ГБ памяти для vSphere 6.7 и vSphere 7.0 U1. На картинке ниже показано число транзакций в секунду с шагом в полсекунды - до, во время и после vMotion (тест HammerDB):

Основные результаты теста:

• Общее время горячей миграции сократилось с 23 секунд в vSphere 6.7 до 11 секунд в vSphere 7.0 U1 (уменьшение в 2 раза)
• Итоговое время для установления трассировки уменьшилось с 2.8 секунд до 0.4 секунд (снизилось в 7 раз)
• Увеличение полосы пропускания где-то на 45% (около 3480 транзакций в секунду, по сравнению с 2403 транзакции в секунду)

Остальные интересные подробности приведены в документе "vMotion Innovations in vSphere 7.0 U1".

Как многие из вас знают, в последние пару лет очень сильно увеличилось число и масштаб атак, связанных с уязвимостями в аппаратном обеспечении. Наибольшую известность получили уязвимости Meltdown и Spectre, которые были обнаружены в процессорах Intel.

Самый неприятный момент, связанный с подобного рода уязвимостями - это то, что поскольку они связаны с аппаратной частью процессоров на самом низком уровне, то, во-первых, ее сложнее исправить и доставить конечным пользователям, а, во-вторых, неправильное обновление, закрывающее эти дырки, может вызвать различные побочные эффекты.

Так, например, было с производительностью серверов VMware ESXi, когда производители ОС совместно с Intel выпустили соответствующие обновления, а VMware выпустила закрывающий уязвимость патч. Сам патч тогда пришлось отозвать и ждать нового, а ведь это потраченного время администраторов, время пользователей и время, в течение которого существует угроза безопасности инфраструктуры предприятия.

Поэтому производители процессоров, совместно с вендорами платформ виртуализации, сейчас уделяют этому моменту особое внимание. Конечно же, в этом направлении работает и AMD, которая активно внедряет следующие технологии:

• Secure Encrypted Virtualization (SEV) - первая версия технологии, анонсированная в 2016 году. Она позволяет изолировать виртуальные машины от гипервизора, со стороны которого может быть угроза безопасности при его компрометации. Если гипервизор попытается считать память гостевой ОС, он увидит только зашифрованные данные.
• SEV-ES (Encrypted State) - вторая версия технологии, представленная в 2017 году. Она дополняет защиту памяти гостевой ОС шифрованием регистров CPU гостевой ОС. Таким образом, гипервизор не может видеть регистры процессора, активно используемые виртуальной машиной.
• SEV-SNP (Secure Nested Paging) - следующее поколение технологии, которое было анонсировано в этом году. Оно добавляет функции аппаратной безопасности для контроля над интеграцией памяти гостевых ОС, что защищает от таких атак, как data replay, memory re-mapping и других (подробнее тут и на картинке ниже).

Надо начать с того, что у VMware уже есть защита памяти и данных гостевой ОС на уровне платформы (а в самих ОС тоже есть средства защиты памяти и процессора), но, само собой, эти механизмы на надежны на 100%, потому что ключевой компонент платформы - гипервизор, обладает очень широкими полномочиями (в виду необходимости), и при его компрометации ничего особо не поможет. Поэтому самое разумное - это поддержать подход изоляции ВМ от гипервизора на аппаратном уровне. Он, кстати, называется Trusted Execution Environment (TEE).

Подход AMD заключается в том, что они добавляют специальный Secure Processor, маленький сопроцессор, интегрированный в основной чип CPU, который является основой безопасности и поддерживает операции шифрования, в том числе и для SEV-ES.

Первое поколение EPYC CPU поддерживало хранение только 15 ключей шифрования, но следующее поколение уже поддерживает более 500. Один из таких ключей используется для гипервизора, а остальные - для гостевых систем.

Для чего вообще нужно защищать регистры процессора гостевых систем? Очень просто - когда виртуальная машина переключает контекст исполнения (меняет процессор), гипервизор получает ресурсы CPU обратно, вместе с содержимым регистров. А в них может храниться много "полезного" для злоумышленника - например, ключи для расшифровки дисков гостевой системы.

Работает механизм ключей так - гостевая ОС запрашивает у процессора с поддержкой SEV ключ шифрования для памяти, а SEV-ES расширяет его и на регистры процессора тоже, после чего гостевая ОС может безопасно использовать память и регистры, не беспокоясь что гипервизор или другие ВМ, изолированные в рамках процессов VMX, считают их содержимое. Очевидно, что гостевая ОС тоже должна поддерживать реализацию SEV-ES (поэтому надо читать соответствующую документацию к ним, чтобы узнать о поддержке).

Самым большим минусом использования технологии SEV-ES является невозможность поддержки таких техник, как vMotion, Memory Snapshots, Guest Integrity, Hot Add, Suspend & Resume, Fault Tolerance и горячих клонов - ведь для их реализации гипервизор должен иметь прямой доступ к памяти гостевых систем. В то же время надо отметить, что это не ограничение от AMD, которая заявляет, что SEV поддерживает live migration и прочее, а ограничение реализации от VMware.

В большинстве производственных окружений невозможность применения этих технологий будет ограничивать использование SEV-ES только системами, требующих наивысшего уровня защищенности.

С другой стороны, например, недавно вышедшее решение vSphere with Tanzu не использует vMotion для машин с контейнерами виртуализованных приложений - они просто выключаются на одном хосте и включаются на другом, то есть здесь есть перспективы применения SEV-ES.

Также использованием технологии SEV-ES можно управлять в пакетном режиме сразу для нескольких тысяч виртуальных машин через интерфейс PowerCLI, что особенно актуально для контейнеров Tanzu. На данный момент VMware еще не опубликовала официальный референс по командлетам для SEV-ES, ждем.

Ну и недавно VMware выпустила интересное видео, рассказывающее о первой имплементации технологии SEV-ES в платформе VMware vSphere 7 Update 1:

Как итог можно отметить, что пока такие технологии, как Secure Encrypted Virtualization имеют достаточно узкое применение ввиду их ограничений. Однако это лишь первые шаги, которые производители процессоров делают совместно с вендорами платформ виртуализации, чтобы защитить ИТ-среду предприятия он новой волны атак на программно-аппаратную инфраструктуру датацентра. Дальше все это будет развиваться, будет и поддержка AMD SEV-SNP, что уже будет существенно уменьшать поверхность возможных атак.